Task: Continuous Integration Build
Integrates the latest changes in the repository and runs automated tests against the release providing feedback to the development team.
Disciplines: Build Management
Purpose

Integrates the latest changes in the repository and runs automated tests against the release providing feedback to the development team.

Relationships
RolesPrimary Performer: Additional Performers:
InputsMandatory:
    Optional:
      Outputs
        Main Description

        The Integration Build is used by the integrating developer (or integrator) to incorporate the most recently completed development tasks into a single, stable, consistent and correct result. The result of a successful integration build is also what is used during a Workspace Update to synchronize the state of an in-progress development task with the latest stable state of the codeline.

        An integration build is preferably a full build (if time and bandwidth allows) whose results visibly impact the progress and coordination of the entire development team and all the active development tasks at that time. The frequency of an integration build may be as often as one per development task (at the end of each task) or may be every few tasks (or even daily/nightly). In some cases, there may be two "flavors" of integration builds: one that is done after every development task and does only an incremental build (and possibly runs only a subset of tests), and one that runs daily or nightly and does a full build and runs a more complete set of tests. In either case, the purpose of the integration build is to centrally coordinate and synchronize all ongoing work in small bits and pieces to avoid "big bang integration" at the end of a release/iteration, and to provide a regular rhythm for the development team to tackle integration issues early and aggressively, one small piece at a time.

        Steps
        Define the build completness

        Define the build completness:
        - Clean full build: The environment should be totally cleaned before the build execution.
        - Incremental build: Other parts from previous build can be reused (It is faster, but less secure) 

        [optional] Merge changes to one single codeline (If changes are in different branches)
        Merge changes to one single codeline (If changes are in different branches)
        Assure Build Environment is similiar to Release Build Environment

        The purpose of having a build envinronment equals (or even much similar) to release build envinroment is to avoid future problems in the release generation.

        Launch Build (Atomatically or Manually)

        Launch Build using the command line with the resolved compile time variabilities if applicable.

        Possibilities:
        Atomatically - Build launched and controlled by continuous integration tools.
        Manually - Build launched and controlled manually by engineers.

        Apply Label on Repository build Configuration (Atomatically or Manually)

        Apply Label on Repository build Configuration

        Possibilities:
        Atomatically - Label applied by continuous integration tools.
        Manually - Label applied manually by build engineers.

        Key Considerations
        This build visibility is to the whole development team.